home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
ospf
/
ospf-minutes-91jul.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
8KB
|
197 lines
CURRENT_MEETING_REPORT_
Reported by John Moy/Proteon
OSPF Minutes
The OSPF Working Group met on Monday, July 29th at the Atlanta IETF. The
following topics were discussed:
OSPF trap MIB
Rob Coltun led a discussion of his OSPF Trap MIB document. Briefly,
this document began as a list of traps to help implementors debug their
code. But Rob has now changed it to include only those traps that would
be of use to a network manager. This has decreased the size of the Trap
MIB significantly. Also, the Trap MIB was separated from the rest of
the OSPF MIB in order to smooth the OSPF MIB's standardization path
(traps are still somewhat controversial).
It was decided that the following changes should be made to the Trap MIB
document. After it is updated, the document will then be submitted to
the Network Management Directorate.
o The ospfIfStateChange and ospfVirtIfStateChange traps will only
occur when either a) the new interface state is one of the terminal
states (``DR'', ``Backup'' or ``Other'') or b) the interface state
regresses (e.g., goes from ``DR'' to ``Down'').
o The ospfNbrStateChange and ospfVirtNbrStateChange traps will only
occur when either a) the new neighbor state is one of the terminal
states (``2-Way'' or ``Full'') or b) the neighbor state regresses
(e.g., goes from ``2-Way'' to ``1-Way'').
o A new authentication failure trap will be created, splitting off
from the existing ospfConfigError trap. This is because for net-
works that are on the boundary of two ASes, authentication failures
may be configured intentionally in order to separate two OSPF
domains.
o The reasons for the ospfRxBadPacket trap will be enumerated, just
as the is currently done for the ospfConfigError trap.
o The ospfOriginateLSA trap will not be invoked for simple refreshes
of LSAs (which happen every 30 minutes), but instead will only be
invoked when an LSA is (re)originated due to topology change.
o The ospfMaxAgeLSA trap will only be invoked for those LSAs that the
router itself ages to MaxAge (either normally or prematurely). It
will not be invoked when the router receives a MaxAge advertisement
from a neighbor.
1
o The ospfFreeLSA trap will be removed, since its functionality is
(pretty much) identical to that of the ospfMaxAgeLSA trap.
Not so stubby areas
Next, Vince Fuller led a discussion of the proposed new ``not so stubby
area'' option for OSPF. Briefly, the intent of this option is to create
a new type of area (the ``not so stubby area'' or NSSA), which would not
receive type 5 external LSAs from the backbone (and so would have a
small database size), but would be allowed to itself originate a small
number of external advertisements for distribution to the backbone.
This would allow small RIP clouds to be hung off of the NSSAs.
Vince Fuller and Rob Coltun are writing a document defining NSSAs. The
intent is to add them in a backward compatible way to OSPF Version 2.
As far as mechanisms for implementing NSSAs, there were two competing
proposals, each differing on how the NSSA would represent the externals
it exports to the backbone.
o Option 1.
The externals would be originated as regular type 5 LSAs. Flooding
of type 5s between an NSSA and the backbone is unidirectional.
Type 5s can be flooded from NSSAs to the backbone, but not vice
versa.
Advantages: 1) No conversion of the LSA would be necessary at the
area border routers connecting the NSSA to the backbone.
Disadvantages: 1) There would no longer be a global type 5
database. In fact, the type 5 database in the area border routers
connecting the NSSAs to the backbone would be split into several
pieces: one for each NSSA, and one for those type 5s originated by
the backbone. Maintaining this split may prove difficult.
o Option 2.
The externals would be originated as a new LSA type (call it type 6
LSAs). The flooding of type 6 LSAs would be restricted to a single
NSSA. The area border routers connecting the NSSA to the backbone
would, in essence, convert the type 6 to a type 5 for distribution
to the backbone.
Advantages: 1) the type 5 database remains intact. In addition,
the flooding of type 6s is similar to the flooding of all other
LSAs that are specific to a single area (i.e., type 1-4s).
Disadvantages: 1) The ``conversion'' of type 6s to type 5s in the
2
border routers may be fairly complicated (editor's note: at lunch
Rob Coltun pointed out that the conversion could be made trivial by
requiring that all type 6s be originated with forwarding
addresses). 2) When there are multiple area border routers
connect- ing the NSSA to the backbone, multiple type 5 LSAs may be
produced for a single type 6 LSA. It was thought that this could be
overcome by an election algorithm, if desired.
Vince and Rob are going to further weigh the two approaches and
then document their conclusions.
Non-broadcast Networks
Several people have noticed that OSPF's non-broadcast support could be
made more robust in the face of misconfiguration, and that the amount of
configuration (especially address translations) could be reduced by
using some of the mechanisms in Paul Tsuchiya's SMDS routing and
addressing internet draft (like ARP servers). We attempted to find
some- one to write a document discussing these issues, but have as yet
been unsuccessful.
Joint Session with BGP Working Group
We also met in a joint session with the BGP Working Group, where we
reviewed Kannan Varadhan's document on BGP and OSPF interaction.
Kannan's document give rules for exporting OSPF routes to BGP, importing
BGP routes into OSPF, and defines how to set the OSPF external route tag
in a vendor-independent manner. It also mandates that the OSPF router
ID and the BGP router ID be set identically, and explains the
circumstances where OSPF and BGP forwarding addresses should be used.
Attendees
Nagaraj Arunkumar nak@3com.com
Jim Beers beers@nr-tech.cit.cornell.edu
Tom Benkart teb@saturn.acc.com
Nelson Bolyard nelson@sqi.com
Scott Brim swb@nr-tech.cit.cornell.edu
Henry Clark henryc@oar.net
Rob Coltun rcoltun@ni.umd.edu
Dave Cullerot cullerot@ctron.com
Dino Farinacci dino@cisco.com
Dennis Ferguson dennis@canet.ca
Arlan Finestead arlanf@ncsa.uiuc.edu
Vince Fuller vaf@stanford.edu
Robert Griffioen
Jeffrey Honig jch@nr-tech.cit.cornell.edu
Phani Jujjavarapu phani@cisco.com
Mark Lewis mlewis@telebit.com
Joshua Littlefield josh@cayman.com
3
Brian Lloyd brian@telebit.com
April Merrill Merrill@dockmaster.ncsc.mil
Greg Minshall minshall@wc.novell.com
John Moy jmoy@proteon.com
Andy Nicholson droid@cray.com
Karen O'Donoghue kodonog@relay.nswc.navy.mil
Norman Patty
Joe Peck peck@ms1.pa.dec.com
Jason Perreault perreaul@interlan.interlan.com
Roxanne Streeter streeter@nsipo.nasa.gov
Mike Truskowski truskowski@cisco.com
Brian Wheeler wheeler@mbunix.mitre.org
4